1. Field of the Invention
The present invention relates to a function of executing only one machine instruction for a program evaluation device, and more particularly, to a procedure step execution for executing a called sub-program together.
In the case of executing program development, one program is made up of a large number of sub-programs (sub-routines). There are many cases in which each sub-program is processed by calling further another sub-program therefrom, thus providing nestings several times over. The procedure for debugging of the program thus structured is not to debug the entire large program from the beginning, but to debug a sub-program from a lower stack of the nesting toward higher stacks sequentially. In this case, because the sub-programs in the lower stacks have been debugged, they need not be called when the higher sub-program is debugged.
For debugging a program, a method of executing steps for each instruction is frequently used, however, it is unnecessary to execute the steps for the sub-program which has been debugged. For that reason, the program evaluation device for debugging the program has a function called "procedure step execution" for executing steps within the sub-program together.
2. Description of the Related Art
A conventional procedure step execution function is to count the number of executions of sub-program call instructions (hereinafter referred to as "CALL") and the number of executions of reset instructions (hereinafter referred to as "RET") from the sub-program, respectively, and to judge that the execution of the sub-program has been terminated when the former is coincident with the latter. Hereinafter, a description will be given of the flow of the respective steps (1) to (7) illustrated in FIG. 9.
In step (1), it is judged whether an instruction to be executed is CALL, RET or another instruction, and in case of CALL, CALL is executed and its occurrence is counted in steps (2) and (3). If it is judged that the instruction is RET, RET is executed and its occurrences is counted in steps (5) and (6). If it is judged that the instruction is neither CALL nor RET, the instruction is executed in step (4), and control returns to step (1) for the execution of the succeeding instruction.
If the executed instruction is CALL or RET, in step (7), the number of occurrences of CALL is compared with that of RET, and if the former is coincident with the latter, it is judged that the execution of the sub-program which has been called initially has been terminated. In this situation, if the former is inconsistent with the latter, it is judged that the execution of the sub-program which has been called initially has not yet been terminated, and control returns to step (1) for the execution of the succeeding instruction.
Subsequently, the conventional procedure step execution will be described in detail with an example of the program shown in FIG. 10. A method of judging the termination of a sub-program which will be described below is slightly different from the method of judging the completion shown in FIG. 9. The method of FIG. 10 substitutes the number of CALL executions for a variable which is COUNT, and COUNT is increased by the execution of CALL but decreased by the execution of RET so that when COUNT is 0, it is judged that the sub-program is terminated. FIG. 10 shows a program for calling and processing sub-programs SUB1 and SUB2 in a program of MAIN, and FIG. 11 shows a schematic diagram of the processing, and a change in COUNT. In FIG. 11, CALL and RET in steps (1) to (5) correspond to steps (1) to (5) in FIG. 10.
First of all, in the case where CALL of (A) is executed, COUNT is increased with the result of COUNT=1; in the case of CALL of (B), COUNT=2; in the case of RET of (C), COUNT=1; in the case of CALL of (D), COUNT=2; in the case of RET of (E), COUNT=1; and in the case of RET of (F), COUNT=0. Thus, the termination of the sub-program is determined.
A circuit for executing the above-mentioned method of judging the sub-program termination will be described with reference to FIGS. 2 and 12.
FIG. 2 is a diagram showing the entire system for conducting program evaluation. Reference numeral 200 denotes a program evaluation device; 218, a host computer for controlling the program evaluation device 200; and 216, a target system controlled by a debugged program. Hereinafter, the respective components of the program evaluation device 200 will be described.
A CPU 202 controls the respective components of the program evaluation device using a ROM 204 and a RAM 203 in which a control program is stored. An evaluation processor 205 has two operation modes consisting of a user mode that executes a program to be debugged and a supervisor mode that conducts debugging. The evaluation processor 205 uses a ROM 207 and a RAM 206 in which the supervisor program is stored at the time of the supervisor mode, and a ROM 209 and a RAM 208 in which a program to be debugged is stored at the time of the user mode. Those ROMs 204, 207, 209 and RAMs 203, 206, 208 are connected to each other through a variety of buses such as an address bus 210, a data bus 211 or a control bus 212. The evaluation bus 205 and a target system 216 are connected through a bus 217. A termination judging circuit 201 determines whether the sub-program has terminated.
For the evaluation of a program, the host computer 218 stores the control program in the ROM 204, the supervisor program in the ROM 207 and the program to be debugged in the ROM 209, respectively, in advance. Needless to say the ROMS may be EPROMs or RAMs. Then, the evaluation processor 205 starts the supervisor program according to the control program to prepare program evaluation. When the evaluation processor 205 is in the supervisor mode, the ROM 209 and the RAM 208 in which the program to be debugged is programmed, a value of an inner register in the evaluation processor 205 according to the execution result of the program to be debugged, and a state within the target system 216 as occasion demands are monitored so that they can be confirmed by the host computer 218.
Upon starting the evaluation of program, the evaluation processor 205 allows a reset signal 213 to be generated from the CPU 202 in the supervisor mode, to initiate a flip flop circuit 1 and an up/down counter 16 (shown in FIG. 12). Then, referring to the ROM 209, it is judged whether an instruction to be executed by the program to be debugged is CALL or other instructions. In the case of an instruction other than CALL, the CPU 202 makes a step execution control terminal 214 active. When a step execution control terminal 10 becomes active, the evaluation processor 205 executes one instruction of the program to be debugged in the user mode, and returns to be in the supervisor mode again. It should be noted that since the step execution control signal 214 is latched by an I/O port 222, the CPU 202 makes the step execution control signal 214 inactive when the evaluation processor 205 returns to be in the supervisor mode.
In the case where the program to be debugged is CALL, the step execution control signal 214 is not made active and executes CALL in the user mode. In this case, the program to be debugged is executed continuously even after CALL is executed. The CALL strobe terminal 11 and the RET strobe terminal 12 of the evaluation processor 205 output 1 level when executing a normal instruction, but when executing CALL or RET, outputs 0 level from corresponding strobe terminals, respectively. This is conducted by microprograms of CALL and RET of the evaluation processor 205.
The flip flop circuit 1 outputs 1 level to a supervisor interrupt request (SVIRQ) terminal 9 since it is reset in advance as described above. An up/down counter 16 up-counts at the rising of a CALL strobe and down-counts at the rising of RET strobe. In other words, the count operation is conducted when the execution of CALL and RET is terminated.
An invertor circuit 15 inverts the output of D0 bit of the up/down counter 16. An 8-input OR circuit 14 outputs 0 level to a line S1 when all of the output of the invertor circuit 15 and the outputs of D1 to D7 bits of the up/down counter 16 are 0, that is, when a value of the up/down counter 16 is 1. An OR circuit 2 outputs 0 level to a line S2 if the RET strobe becomes 0 level when the line S1 is 0 level. The flip flop circuit 1 is set when the line S2 becomes 0 level, and thereafter outputs 0 level to an SVIRQ terminal 9. The evaluation processor 205 stops the execution of a program to be debugged when an SVIRQ terminal 9 becomes 0 level, and returns to be in the supervisor mode.
In conclusion, when RET is executed in a state where the count value of the up/down counter 16 is 1, it is judged that the execution of the sub-program is terminated.
FIG. 13 is a timing chart showing the operation of a sub-program termination judging circuit when the program shown in FIG. 10 is operated. In the figure, the respective symbols are common to those in FIG. 12. CALL strobes at times t1, t5 and t13 and RET strobes at times t9, t17 and t21 correspond to CALLs of (A), (B) and (D) and RETs of (C), (E) and (F) in FIG. 11, respectively. Count values (D0, D1, D2 to D7) of the up/down counter 16 become 1 at times t2 to t5, t10 to t13, t18 to t21, and the line S1 becomes 1 correspondingly. Further, since the RET strobe is generated at time t21, the line S1 and the line S2 become 0 level at the same time, and the subsequent SVIRQs become 0 level.
There is a case in which the program evaluation device using the above sub-program termination judging method is not normally operated in the case of using a real time OS as an OS or in the case of conducting a branching process of the sub-program (restart call) such that a certain program calls itself.
Hereinafter, a description will be given of problems caused when conducting the conventional sub-program termination judging method with a real time OS. The real time OS is an OS that operates while switching a plurality of programs that are divided into units which are called "task" according to the situation, and a task under execution is switched by issuance of a system call to OS or occurrence of an event due to interrupt. Also, the task is divided into several sub-programs as in the normal program and developed.
There is a case in which CALL is not coincident with RET in the number of times of execution due to switching of the tasks. Hereinafter, the number of times of execution of CALL and RET in the case of using the real time OS will be described with an example of program shown in FIG. 14. This program is that MAIN_A, SUB1_A, and SUB2_A belongs to a program group of TASK_A, and MAIN_B and SUB1_B belongs to a program group of TASK_B. The TASK_A and TASK_B are program groups independent from each other, and therefore there is no case in which TASK_A calls TASK_B. Also, "CALL SYS_CALL" issues a system call to the real time OS.
FIG. 15 is a schematic diagram showing a processing when executing the program shown in FIG. 14, and represents a state in which an executing process with a time being elapsed is switched to TASK_A, TASK_B and a real time OS. In this case, the executed task is switched to TASK_B over TIME 3 to TIME 4.
FIGS. 16 and 17 show the flows of processes of TASK_A and TASK_B in detail, respectively. CALLs and RETs of (2) to (11) in FIGS. 16 and 17 correspond to (2) to (11) in FIG. 14. Also, in FIGS. 16 and 18, symbols (A) to (M) are indicated in correspondence with the flow of processes, and (A), (E) and (H) are RET when the real time OS returns to TASK_A, and (K) is RET when the real time OS returns to TASK_B. It should be noted that the operation of returning from the real time OS to the task is conducted by managing OS by itself. FIGS. 18 and 19 show the address values and the contents of stack of a stack pointer after CALL and RET have been executed. In this example, it is assumed that the stack region of TASK_A is 0F740H to 0F77FH, and the stack region of TASK_B is 0F700H to 0F73FH. At the real time OS, individual stack regions are assigned to each task, and when the task is switched, the stack region is also switched together. In other words, the sub-program can be called individually for each task.
Hereinafter, a case of executing the procedure step of "CALL SUB1_A" of (2) in FIG. 14 will be described with reference to FIG. 16. In this case, processing flows in the order of (B), (C), (D), (K), (L), (M), (E), (F), (G), (H) and (I). In other words, six CALLs and four RETs are executed. Hence, because CALL and RET are different in the number of times of execution, a case of using the conventional sub-program termination judging method suffers from such a problem that it is judged that the sub-program SUB1_A is not terminated even after the execution of RET of (1).
There is a case in which the conventional program evaluation device incorrectly determines the termination of the sub-program which is called by the program to be debugged in the case of applying the real time OS as an OS of the program to be debugged.
Also, even in the case of using no real time OS, since the conventional program evaluation device determines the termination of sub-program by the number of times of execution of CALL and RET, the termination of the sub-program cannot be judged without using this. In other words, there is a case in which, when the processing of the program returns from a subordinate sub-program to a superordinate program, means is used which extracts an address value latched in the stack from a certain register (stack extraction instruction POP), and then branches it to the address value of that register (branch instruction BR). If such a means is applied when the processing returns from the sub-program to a main program, CALL is not coincident with RET in the number of times of execution. Hence, the termination of the sub-program cannot be correctly judged.